Part 3: Cryptographic Key Lifecycle Policy
| Item | Content |
|---|
| Document Name | Part 3: Cryptographic Key Lifecycle Policy |
| Product Name | DTA Wide Sleep Management Platform |
| Date | 2026-06-17 |
| Scope | Part 3 (Backend/Infrastructure) |
| Related Articles | BSI TR-03161 O.Arch_3 (P.3-010), O.Cryp_4 |
| Reference Standards | BSI TR-02102-1, BSI TR-02102-2, NIST SP 800-57 Part 1/2 |
1. Purpose and Scope
This document defines the lifecycle policy for all cryptographic key material used by the DTA Wide backend system. The policy covers the random number source, key segregation of duties, key/certificate expiration, and integrity assurance through hashing, and is based on the recognized standards BSI TR-02102 and NIST SP 800-57.
The key lifecycle is managed in six stages: Generation → Storage → Usage → Rotation → Backup → Destruction.
2. Key / Secret Catalogue
2.1 Backend Keys
| Key ID | Purpose | Algorithm | Key Length / Bit Strength | Storage Location | Rotation |
|---|
CONSENT_HMAC_KEY | Consent tamper-protection HMAC signing | HMAC-SHA256 | 256-bit (min 32B) | GCP Secret Manager → Cloud Run env injection | Annual (manual) + immediate on compromise |
AUTH_OAUTH_FBETA_EID_CLIENT_SECRET | fbeta eID OAuth2 client authentication | Bearer secret | min 32B random | GCP Secret Manager → Cloud Run env injection | Annual + fbeta policy |
EID_FBETA_JWKS_URL | fbeta IdP JWKS endpoint (URL) | n/a | n/a | GCP Secret Manager | On change (after fbeta notice) |
JWT_SIGNING_KEY | Backend access/refresh token signing | HS256 or RS256 | 256-bit / 2048-bit | GCP Secret Manager | Infrastructure policy |
2.2 Client (Mobile) Keys
| Key ID | Purpose | Algorithm | Key Length | Storage Location | Rotation |
|---|
| Native 2FA device key | ECC Challenge-Response signing | ECDSA P-256 | 256-bit (prime256v1) | iOS Secure Enclave / Android Keystore (non-exportable) | On user reenroll |
| AppCheck attestation key | iOS App Attest / Play Integrity | iOS: P-256 / Android: key-based attestation | 256-bit (iOS) / system-determined (Android) | iOS Secure Enclave / Android Keystore | OS policy |
| Email OTP code | One-time email verification code | random | 6-digit / 30-min TTL | Not stored on mobile — backend Redis cache only | n/a |
2.3 Public Keys Received/Stored by Backend
| Key ID | Purpose | Algorithm | Storage Format | Storage Location | Rotation |
|---|
UserDeviceAuthentication.publicKeySpki | Native 2FA verification | ECC P-256 SPKI DER (base64url) | DB column | private.user_device_authentications.public_key_spki | On user reenroll/change |
| fbeta JWKS public keys | id_token signature verification | RS256 / ES256 | JWK (JSON) | Memory cache (jose, 1h TTL) | Per fbeta JWKS rotation |
EidLink.eidHash | eID identifier one-way hash (1:1 matching / duplicate-link prevention) | SHA-256 | hex string | private.eid_links.eid_hash (UNIQUE column) | Permanent (1:1 user mapping) |
3. Key Lifecycle Stages
3.1 Generation
| Key | Generation Method | Random Source | Integrity Assurance |
|---|
CONSENT_HMAC_KEY | GCP Secret Manager + openssl rand -base64 32 | OS CSPRNG (/dev/urandom) | SHA-256 fingerprint recorded separately |
AUTH_OAUTH_FBETA_EID_CLIENT_SECRET | Issued by fbeta → stored in Secret Manager immediately | fbeta CSPRNG (external responsibility) | Issuance timestamp + version recorded |
| Native 2FA device key | iOS SecKeyGeneratePair (Secure Enclave) / Android KeyPairGenerator (KeyStore) | OS CSPRNG | Generated in secure element → non-exportable |
| Session/OAuth state nonce | Node.js crypto.randomBytes(32) | OS CSPRNG | Single-use, TTL 5–10 min |
Generation Authority:
- Secret Manager
roles/secretmanager.admin holders (infrastructure operators) only
- General developers are read-only (
roles/secretmanager.secretAccessor)
3.2 Storage
| Key | Storage Location | Access Control |
|---|
| Backend secrets | GCP Secret Manager (region: europe-west3) | IAM-based, audit log recorded automatically |
| Runtime environment variables | Cloud Run container env (Secret Manager → env binding) | Container memory only, masked in logs |
| Mobile keys | iOS Secure Enclave / Android Keystore | OS-enforced — non-exportable |
| Backend public keys | PostgreSQL DB column | Repository userId filter enforced |
Secrets are never stored in source code/repository; they are injected only as runtime environment variables from Secret Manager. Sensitive values are masked when written to logs.
3.3 Usage — Single-Purpose Principle (O.Cryp_4)
| Key | Single Purpose | Usage Site |
|---|
CONSENT_HMAC_KEY | Consent HMAC signing only | ConsentHmacService.sign/verify only |
AUTH_OAUTH_FBETA_EID_CLIENT_SECRET | fbeta OAuth client auth only | fbeta token endpoint exchange only |
| Native 2FA device key | Challenge-Response signature verification only | Native 2FA signature verification service only |
JWT_SIGNING_KEY | Session token signing only | Session issuance service only |
To ensure keys are not used outside their purpose, the following controls apply:
- ConfigService namespace separation isolates key access paths
- Keys accessed only in the service layer; direct Controller/Repository access prohibited
- TypeScript strong typing + private fields block export
3.4 Rotation
| Key | Policy |
|---|
CONSENT_HMAC_KEY | Manual (annual) + immediate on compromise. Automated rotation is currently not implemented and is under consideration for a future KMS upgrade (roadmap). |
| fbeta JWKS | Automatic — jose library 1h cache, refreshed automatically on JWKS rotation |
| Native 2FA device key | User-triggered — on reenroll / change |
Manual Rotation Procedure (CONSENT_HMAC_KEY example):
- Add new version in Secret Manager
- Dual-key window (24h): deploy so both new and old keys verify
- After 24h, confirm signatures from the old key are fully verified
- Destroy old key
- Update Cloud Run env (rolling deploy)
- Record rotation in audit log
Immediate Rotation Trigger (Compromise):
- On suspected security incident, destroy immediately + create new version
- Affected signatures are invalidated — user re-authentication required
- Recorded per internal incident response procedure
3.5 Backup
| Key | Backup Mechanism |
|---|
| Backend secrets | Secret Manager versioning — all versions retained, rollback possible |
| Native 2FA device key | OS secure element (Secure Enclave/Keystore) — key itself non-exportable, recovered only via user reenroll |
| Public keys (DB) | Included in PostgreSQL regular backups (same-region multi-zone) |
No separate plaintext backup of secrets is created; Secret Manager versioning provides the recovery mechanism.
3.6 Destruction
| Key | Destruction Reason | Destruction Method | Destruction Verification |
|---|
CONSENT_HMAC_KEY old version | 24h after rotation complete | Secret Manager version destroy | audit log + DESTROYED state in console |
AUTH_OAUTH_FBETA_EID_CLIENT_SECRET | fbeta contract end or rotation | fbeta revoke + Secret Manager destroy | fbeta notice + audit log |
| Native 2FA device key | User reenroll, app deletion, backup expiry | OS auto-deletion + DB status = EXPIRED | cleanup log |
| fbeta JWKS cache | 1h TTL auto-expiry | jose internal cleanup | n/a |
Destroyed secrets are non-recoverable; Secret Manager destroy is permanent deletion.
4. Segregation of Duties
4.1 GCP IAM Role Separation
| Role | Permission | Granted To |
|---|
roles/secretmanager.admin | Key create/rotate/destroy | Infrastructure operators (limited, approval process) |
roles/secretmanager.secretAccessor | Runtime key read | dta-wide-api service account only |
roles/logging.viewer | Secret Manager audit log review | Security audit |
Developers cannot directly access production secrets. Local development uses dev/local secrets or stub mode.
4.2 Audit Log
- All Secret Manager access (read/write/destroy) is recorded automatically in Cloud Logging
- Logs are aggregated into the central logging repository (BigQuery) to counteract deletion/manipulation on source systems
- Alerting on suspicious activity
5. Integrity Assurance
| Mechanism | Application |
|---|
| Key fingerprint (SHA-256) | Recorded at generation, compared at rotation |
| Secret Manager versioning | All change history recorded automatically, rollback possible |
| Audit log | Access/change actions recorded in Cloud Logging |
| Destroy approval process | Production secret destroy requires an approval process |
| Periodic review | Periodic Secret Manager inventory review |
| Key / Algorithm | BSI TR-02102-1 | NIST SP 800-57 Strength | Conformance |
|---|
| HMAC-SHA256 (256-bit) | §4.4.1 recommended | 128-bit security | ✅ |
| ECDSA P-256 + SHA-256 | §4.3.3 recommended | 128-bit security | ✅ |
| RSA 2048 (fbeta JWT) | §4.3.2 min 2000-bit | 112-bit security (valid until 2030) | ✅ |
| TLS 1.3 + AES-256-GCM | §3.3.1 recommended | 256-bit security | ✅ |
| SHA-256 (one-way hash) | §4.3 recommended | 128-bit collision resistance | ✅ |
All algorithms meet the BSI TR-02102-1 recommended criteria, and key lengths are at or above the NIST recommended security strength.
6.1 Algorithm Sunset Plan
- When BSI/NIST raise the recommended criteria, this document is updated and a migration plan is established.
- All current algorithms retain validity beyond 2030.
7. Review Cycle
- Annual periodic review (next: 2027-05)
- Immediate review on security incident
- Ad-hoc updates reflecting external audit feedback
8. Evidence and References (Artifacts)
- Key Catalogue (Section 2 of this document)
- Lifecycle Stage Policy (Section 3 — Generation/Storage/Usage/Rotation/Backup/Destruction)
- IAM Role Separation Matrix (Section 4.1)
- Standards Conformance Mapping (Section 6 — TR-02102-1 / NIST SP 800-57)
| Regulation | Requirement | Implementation | Evidence |
|---|
| BSI TR-03161 O.Arch_3 | Documented crypto key lifecycle policy | This policy (random source / segregation of duties / expiration / integrity) | This document |
| BSI TR-03161 O.Cryp_4 | Single-purpose key usage | Section 3.3 single-purpose controls | This document |
| BSI TR-02102 / NIST SP 800-57 | Based on recognized standards | Section 6 conformance mapping | This document |